Below I will outline improvements for data interoperability regarding Wilderness Study Areas in the United States: https://en.wikipedia.org/wiki/Wilderness_study_area

OpenStreetMap tagging: (main article:osm.wiki/United_States/Public_lands#Guidelines_for_tagging_conservation_areas)

Wikidata identifiers: Instance of: Wilderness study area

Wikimedia Commons Wikidata Infobox template: {{Wikidata Infobox|qid=*}} Images Locator Maps PDFs of wilderness plan/study documents

A few days ago, I asked the community about converting general GIS polygons into OSM multipolygon relations. I’ve searched online but haven’t found a workflow that fits my needs. Specifically, I am looking for a way to handle three different levels of administrative boundaries where adjacent areas share a single boundary line connected via a relation.

My question on the OSM forum is still awaiting a solution: Link

However, someone from my local community mentioned that what I’m looking for is “topology.” While that is a broad GIS term, they clarified that TopoJSON is a specific format designed for this. There are many converters available to turn GeoJSON into TopoJSON.

Interestingly, I found that someone opened a ticket for a TopoJSON converter in JOSM back in 2020, but it hasn’t received a response yet: Link

I’m planning to update and expand the administrative boundaries for Bali in OSM. I’ve already prepared the multipolygons for admin_level 5, 6, and 7 using single shared ways for efficiency. By leveraging Google Sheets, I’ve also compiled a comprehensive list of Wikidata, Wikipedia links, and multilingual names to better serve Bali’s international profile.

However, the conflation process is proving to be a challenge. The existing data is quite a “nightmare” to clean up; many roads and waterways are currently shared with administrative relations, and landuse or natural features are glued to the boundaries. Time to start untangling!

O víkendu jsem se vydal na malý výlet vlakem. Nastoupil jsem do vozu GW Train, který mne vezl až do Horní Plané u Lipna. Jedu s tímto dopravcem poprvé a je to všechno v pohodě. Těším se na vycházku a výstup na rozhlednu Dobrá voda.

Posadím se a hned si všimnu, že na stěně vozu je uchycena široká obrazovka infopanelu. Ukazuje aktuální stanici a v druhé části obrazovky je vyobrazena mapa s pohybujícím se bodem na trati.

Vlak projíždějící Českým Krumlovem, foto Aktron, CC BY-SA 4.0

Ani nemusím jít blíž, abych rozeznal, že ta mapa je OpenStreetMap a že mě toto malé objevení udělalo radost. Je to jedna z mnoha praktických použití mapy, která nemusí být jen na počítači, nebo v mobilu.

Při výletu po Horní Plané si všímám dalších nových detailů a zajímavostí ve městě. Horní Planou jsem před časem mapoval. Teď si ji konečně prohlížím naživo.

… See full entry

Memetakan batas administrasi di Indonesia bisa jadi cukup rumit, terutama saat menghadapi nama wilayah yang serupa. Berikut adalah alur kerja (workflow) sederhana saya dalam menyiapkan data tersebut:

1. Sumber Data

Pertama, unduh data spasial resmi dari Peta Rupa Bumi oleh Badan Informasi Geospasial (BIG). Data ini berfungsi sebagai sumber geometri utama.

2. Ekstraksi Titik Lokasi (Place Nodes)

Karena data sumber berbentuk poligon, saya menggunakan QGIS untuk mengekstrak titik tengah (centroid). Titik-titik ini penting untuk membuat tag place=* yang mewakili pusat dari tiap wilayah administrasi.

3. Pentingnya Kode Kemendagri

Poligon tersebut mencakup kode referensi Kemendagri. Kode ini sangat vital untuk:

• Konflasi: Memastikan data cocok dengan set data lainnya.

• Identifikasi: Banyak desa (admin_level 7 atau 8) memiliki nama yang sama. Kode ini membantu membedakannya dalam satu Kabupaten atau Provinsi.

4. Pengayaan Metadata

Menggunakan alat spreadsheet dan teknik konflasi, saya mencocokkan data untuk menambahkan:

• Tag wikidata dan wikipedia.

• Nama dalam berbagai bahasa (name:en, dsb).

5. Pengolahan Geometri

Sesuai dengan praktik terbaik (best practices) di OSM, saya mengubah poligon menjadi garis terpisah (polylines).

• Hal ini memungkinkan wilayah yang bertetangga untuk berbagi satu garis batas yang sama melalui relasi multipolygon.

• Setelah dikonversi, saya mengekspor hasilnya dalam format .geojson.

6. Pengetagan Akhir (Final Tagging)

Terakhir, saya menggunakan titik lokasi (place nodes) yang telah diekstrak sebelumnya untuk menyalin dan menempelkan tag yang relevan ke dalam relasi multipolygon baru di editor OSM.

Mapping administrative boundaries in Indonesia can tricky especially when dealing with overlapping names. Here is my simplified workflow for preparing this data:

1. Data Sourcing

First, download the official spatial data from Peta Rupa Bumi by Badan Informasi Geospasial. This serves as the primary geometry source.

2. Extracting Place Nodes

Since the source data is in polygon format, I use QGIS to extract the centroids (points). These points are essential for creating the place=* tags that represent the center of each administrative area.

3. The Importance of Kemendagri Codes

The polygons include Kemendagri reference codes. These are vital for:

• Conflation: Ensuring data matches across different sets.

• Identification: Many villages (admin_level 7 or 8) share the same name. The code helps distinguish them within a Regency or Province.

4. Enriching Metadata

Using spreadsheet tools and conflation techniques, I cross-reference the data to add:

• wikidata and wikipedia tags.

• Multilingual names (name:en, etc.).

5. Geometry Processing

To follow OSM best practices, I convert the polygons into independent ways (polylines).

• This allows adjacent areas to share a single boundary line via a multipolygon relation.

• Once converted, I export the result as a .geojson file.

6. Final Tagging

Finally, I use the previously extracted place nodes to quickly copy and paste the relevant tags into the new multipolygon relations in my OSM editor.

Comme ailleurs dans le monde, les installations photovoltaïques se multiplient en Belgique. En 2022, 68 ans après les débuts du photovoltaïque, la capacité mondiale en panneaux photovoltaïques atteignait son premier TW. Il n’aura fallu que 2 ans pour que 1 TW supplémentaire soit ajouté en termes de capacité mondiale en 2024. Et le rythme s’accélère encore.

En Belgique, d’après electricitymaps, il y aurait une capacité installée de 11.5 GW, soit environ 1 kW par habitant, une puissance à peu près équivalente à la charge électrique moyenne du pays. Toutefois, difficile de trouver des chiffres précis, à jour et encore moins la répartition spatiale de ces installations.

Récemment, je vois passer l’info que l’équipe du géoportail wallon travaille justement sur un inventaires des installations photovoltaïques au sol. Du coup, j’en ai profité cette semaine de faire un tour des centrales solaires de Wallonie (la moitié sud de la Belgique) enregistrées dans OSM, en vérifiant les données et les complétant. J’ai même découvert et ajouté quelques centrales photovoltaïques.

Mais comment les ajouter dans OSM ?

Il y a une très grande diversité d’installation photovoltaïques: depuis le panneau isolé sur un balcon ou la toiture d’une maison, jusqu’à la centrale solaire photovoltaïque de plusieurs MW, composé de milliers de panneaux. Dans OSM, on distingue d’une part les centrales solaires et d’autre part les panneaux solaires. Les centrales solaires photovoltaïques sont constituées d’un ensemble de panneaux, tandis que les petites installations sont composés uniquement de panneaux.

Dans OSM, on ajoute une centrale solaire avec les tags “power=plant” + “plant:source=solar” + “plant:method=photovoltaic” + “plant:output:electricity=*” (voir le wiki osm.wiki/Tag%3Aplant%3Asource%3Dsolar). On dessine généralement une surface qui englobe les panneaux, qui sont plus ou moins espacés selon les cas, et uniquement pour les “grosses” installations.

… See full entry

Люди, кто пишет в дневниках: вот, я стал картографом,..мне это всё понравилось,…ура ура ура… Большая просьба: не превращайте только карты в игру для развлечений! Не вносите правки и не присваивайте имён, если вы Лично не проводили исследования в данном районе! Надеюсь что большинство прочитавших всё-таки поймут меня.

Es macht besonders Spaß, draußen an der frischen Luft zu kartieren. Gerade jetzt, wo es wieder wärmer wird, ist das durchaus eine angenehme Art zu mappen. Doch das wäre ohne bestimmte Tools gar nicht möglich. Da dein Smartphone selbstverständlich um einiges kleiner als ein PC-Bildschirm ist, ist es wichtig, die richtigen Tools auf dem Handy zu haben, um den Überblick zu behalten und effizient arbeiten zu können. Doch welche Apps eignen sich für dich? Und überhaupt: Welche Apps gibt es da eigentlich?

1. Einsteigerfreundlich, schön und einfach: StreetComplete

Um StreetComplete kommst du nicht drumrum. Es ist einfach zu bedienen, schön gestaltet und vor allem gamifiziert. Und genau dieser zugrunde liegende spielerische Ansatz macht die App so gut. Statt die Tags manuell für Objekte einzutragen, sucht die App nach fehlenden Tags, die du dann durch die Beantwortung einer Frage hinzufügen kannst. Zudem gibt es Abzeichen, Statistiken und Rankings, die dich motivieren weiterzumachen. Meiner Meinung nach macht die App aber auch ohne diese schon süchtig genug …

2. Da geht noch mehr: SCEE (StreetComplete Expert Edition)

SCEE ist prinzipiell eine abgewandelte Version von StreetComplete. Ihr Ziel ist es, die App auch für dich als etwas fortgeschritteneren Mapper zugänglich zu machen. So lassen sich Tags anzeigen und bearbeiten, mehr Fragen zu spezielleren Tags aktivieren und diese sogar leicht modifizieren. Ich persönlich nutze dieses Tool hauptsächlich, da es für mich den besten Kompromiss zwischen Übersichtlichkeit bzw. schönem Design und tieferem Mapping bietet. Wichtig zu wissen: Du findest diese Version meist nicht im Play Store, sondern musst sie über F-Droid oder GitHub beziehen.

3. Anwender und Beitragender zugleich: OsmAnd

… See full entry

🗺️ Entry 1 — Setting up JOSM & Plugins

Mapping Banjë, Albania

I started mapping the Banjë region in Albania by setting up my editing environment in JOSM.

⚙️ Setup

I configured JOSM with a set of plugins to support structured mapping and validation:

• utilsplugin2 – general productivity tools
• reltoolbox – relation and multipolygon editing
• waydownloader – working with connected geometries
• merge-overlap – cleaning overlapping features
• Relation Validation Plugin – checking data consistency
• FastDraw – faster geometry digitizing

I also explored additional plugins like contour-related tools for terrain-based mapping.

🗺️ Mapping Context

The focus area is Banjë (central Albania) — a landscape with: - Complex terrain (valleys, rivers, slopes)
- Mixed land use (forests, agriculture, settlements)
- Incomplete or inconsistent OSM coverage

🌱 Initial Observations

• Landuse classification is often fragmented or overlapping
• Boundaries between forest, farmland, and settlements are not always clear
• Many features require clean multipolygon structures
• Validation tools already highlight conflicts in relations

🎯 Next Steps

• Clean and structure landuse polygons (forest, farmland, residential)
• Resolve relation conflicts and validation errors
• Improve consistency of tagging using presets
• Start refining settlement structures and road connectivity

Gashamo Hawd Somali Ethiopia is the city of Hawd Zone Somali Regional State of Ethiopia.

Gashamo Hawd Somali Ethiopia is the city of Hawd Zone Somali Regional State of Ethiopia.

เลขที่ 93/324 ถนนสุขุมวิท แขวงบางจาก เขตพระโขนง กรุงเทพมหานคร 10260

So, I’ve been using Altilunium LocationPad for several of my personal projects until now. But recently, I encountered several problems.

I dabble with multiple projects at once, but this app saves everything in a single database. I want this app to be able to create several separate “canvases”, so I can manage several of my projects at once, without mixing them with other projects.

… See full entry

[English] BetterIME is a JOSM plugin that automatically manages Chinese IME state based on focus context, preventing IME from intercepting keyboard shortcuts while editing the map. GitHub: https://github.com/nj-yzf/josm-BetterIME

---

问题背景

使用中文输入法编辑 OpenStreetMap 时，JOSM 的快捷键（如 S 选择、A 添加节点、W 提高路径精度等）经常被输入法拦截，导致快捷键失效。每次都要手动切换输入法，非常影响编辑效率。

为此我开发了 BetterIME 插件，让 JOSM 根据当前操作场景自动控制输入法状态。

功能介绍

插件将输入法控制分为三种场景：

自动切换至中文输入法： - 编辑 name、name:zh、name:zh-Hans、name:zh-Hant、alt_name、operator 标签时 - 打开 F3「搜索预设组合」对话框时

默认英文，可手动切换： - 其他文本输入框（如 Ctrl+F 查找、其他标签编辑等）

禁用输入法（快捷键正常工作）： - 地图视图、工具栏等非文本组件，Shift/Ctrl+Space 也无法意外切换至中文

此外，插件还释放了 Ctrl+Space 快捷键（JOSM 默认绑定为「搜索菜单项」），让它回归系统输入法切换功能。

首选项设置

通过 编辑 → 首选项 (F12) 打开 BetterIME 设置页，可以：

• 启用/禁用自动输入法切换（总开关）
• 启用/禁用 F3 搜索预设对话框中的中文输入法
• 启用/禁用基于标签键的自动检测
• 自定义触发中文输入法的标签键列表（支持添加、删除、重置）

所有设置即时生效，无需重启 JOSM。

安装方式

方式一：JOSM 内置插件管理器 1. 打开 编辑 → 首选项 → 插件 2. 搜索 BetterIME 3. 勾选启用，重启 JOSM

方式二：手动安装 1. 从 GitHub Releases 页面下载 BetterIME.jar：https://github.com/nj-yzf/josm-BetterIME/releases 2. 将 JAR 文件复制到 JOSM 插件目录（Windows: %APPDATA%\JOSM\plugins\） 3. 在 编辑 → 首选项 → 插件 中勾选启用，重启 JOSM

兼容性

• JOSM 19555 及以上版本
• Java 11 及以上
• 目前仅在 Windows 上测试过，macOS 和 Linux 上的输入法框架不同，可能无法正常工作，欢迎反馈测试结果

反馈

如果遇到问题或有功能建议，欢迎在 GitHub 提交 Issue：https://github.com/nj-yzf/josm-BetterIME/issues

许可证：GPL-2.0-or-later（与 JOSM 一致）

I was recently reading Demographic deposit, dividend and debt by Sonalde Desai. Following the Standard Operating Procedure, I looked up this Sonalde person and turns out she is a researcher at a research institute in Delhi called National Council of Applied Economic Research. The work of this organization felt interesting to me, so I had to pause my studies and see its location on OpenStreetMap.

Nothing. Looks like the place hasn’t been mapped yet. I searched for 11, Indraprastha Estate since that was mentioned on their contact page and this time I did find an object. A person called “n’garh” had added the address back in July 2014 and I am so glad that I was quickly able to push a changeset (#180878526). Another win for address mapping!

This post was first released on my website with 💜 under CC BY-NC-SA 4.0.

Hey everyone,

the new version of UrbanEye3D, namely 2.0.0, is out!

This is a major update for the plugin. It’s been a lot of work and took about 2.5 months, but I’m confident it makes the 3D view significantly more useful and enjoyable to work with.

For those who haven’t heard of UrbanEye3D before: it’s a JOSM plugin that renders a 3D world from OpenStreetMap data directly inside JOSM. This lets you preview objects in 3D before uploading your changes to the OSM database.

What’s New

1. 2D Ground Plane

Buildings no longer float. The ground surface is displayed with “flat” objects - roads, lawns, rivers, and lakes. This flat layer is rendered based on downloaded OSM data using a custom MapCSS style. Alternatively, a satellite background can be enabled, as before.

2. Trees

… See full entry

I just published a hacky but effective tool to fix wrong tag values. This lead to some 50 edits only this morning.

More info: https://www.grulic.org.ar/~mdione/glob/posts/correcting-openstreetmap-wrong-tag-values/

これは2026-04-04に開催予定の「OSM Japan」への説明資料です

ことの発端

無限の刃に「int_name」の削除をやめるよう促した

• ことの発端は 2025-07-02 に無限の刃から私に送られてきた「変更セット167515107」の議論に始まります

この変更セットでは無限の刃が * int_nameをname:enに書き換えています。

2025-06-28 from 無限の刃
あなたの編集による、名称キー使用法の誤りを修正しました。交差点名は明白に英語であり、国際名キー「int_name」から英語名キー「name:en」に変更しました。また、削除された日本語名キー「name:ja」再追加しました。これらの私による編集は、OSM Wiki の記述に基づきます。 [https://wiki.openstreetmap.org/JA:Key:name](https://wiki.openstreetmap.org/JA:%E5%A4%9A%E5%9B%BD%E8%AA%9E%E3%81%AE%E5%90%)

※ 原文は変更セット167515107

この時点では、「交差点名は明白に英語であり」との記述以外はよくある「int_name」を知らない人の反応なので、いつもどおり情報源の確認のために返信を送りました

2025-07-03 to 無限の刃
あなたが追加したという「name:ja」の情報源は何でしょうか？
単に[name=*]の値をコピーしただけでしょうか？もし、コピーならその情報は冗長な情報です。
また、「name:en」の情報源は何でしょうか？
もし、「int_name」以外の情報源から「name:en」を持ってきたのならその情報源を明示して、「int_name」と併記してください。
「int_name」単なる「英語表記」以上の意味が含まれています。
変更セットのコメントに示したように、Mapillaryの画像を解析して主に信号機等に付属している「案内標識」の”観光客むけの表記”の部分を確認し、現地の状況と一致している確認が取れたものを「int_name」に昇格させています。「name:en」では単なる「翻訳名」の可能性がありますが、「int_name」にすることで「現地に表示された表記」を示しています。
地名等が現地でどのように表記されているかというのはとても重要な情報ですので「int_name」を軽々しく削除しないでください。 

※ 原文は変更セット167515107

• これ以後、無限の刃からの返信は非常に長文で意味不明な記述になりましたので割愛します。

2025-08-01 to 無限の刃
再度警告いたします。
「int_name」を機械的に削除するする前にコニュニティーによる「検討」が必要です。
ご自分が正しいと確信しているのならコミュニティでのコンセンサスを取り付けてください。 

DWG登場

2025-08-03 from DWG Glassman
DWGは、推奨タグのname<:xx>ではなく、int_nameタグを使用していることに関する苦情を受けました。詳細はosm.wiki/Key:nameをご確認ください。
日本に関する詳細は、https://wiki.openstreetmap.org/Multilingual_names#Japanをご参照ください。
int_nameタグの使用を中止することに同意いただけますか？

※ 原文は「[`int_name`を廃止する提案](https://community.openstreetmap.org/t/key-int-name-must-be-deprecated/142316)」

DWGからのメールには問題があります

• DWGはコミュニティの合意やOSMwikiの記載事項を無視して『int_nameタグの使用を中止』するよう強制してきました

2025-08-03 Glassmanへ日本の「int_name」の重要性を説明しました

• To Glassman : 『具体的な例や「int_name」が必要な理由および問題点を示しましたので https://wiki.openstreetmap.org/JA_talk:Key:name をご覧ください。』
• To Glassman : 『日本には「int_name」が実存しますので、地物として存在するものを使ってはいけないとする合理的な理由を示していただけないでしょうか？』

2025-08-03 DWGからの返信

… See full entry